As the digital home and internet grow rapidly, the home network communication protocols, integration platforms, and middlewares are developed. As there exists no consensus on the digital home architecture and framework, there is neither a consensus on the standard protocol for the digital home. Therefore, the integration of different network communication protocols and networks becomes the most important issue in the digital home development. The open service platform proposed by the Open Services Gateway Initiative (OSGi) Alliance is one of the solutions.
In the most recent OSGi standard, only two connection types that can be converted to control the devices connected to an open service gateway are defined. The first is the Device Access standard, defining how to download a corresponding driver for a physical device connecting to an open service gateway (OSG). The second is through the network connection to convert to the universal plug and play (UPnP) standard. Through the conversion to the UPnP device service, the service can be provided to the internal bundles or the control devices of an external UPnP control point.
In general, in most digital home applications, the devices are not all connected to an open service gateway. Not all the devices have powerful network communication capability. The common connection for most devices is connected through a simple device with simple functions to a more powerful control gateway for external communication. The control gateway acts as a window to indirectly control the simple devices connected to the control gateway. For example, the home security layout is through a plurality of simple sensors, connected to a more powerful control host for overall control.
Another example is the LonWorks network layout for a smart home, including several LonWorks standard devices, connected to a LonWorks server. Through the LonWorks server, the goal of indirect control of LonWorks standard devices is achieved. In this architecture, it is usually impossible to directly communicate with the devices connected to the control gateway, and the communication must be accomplished through the control gateway. The present OSGi standard does not specify the connection method for controlling the connected devices through the control gateway.
The current OSGi standard defines only two solutions for network communication protocols, namely, UPnP and Jini, including how to convert the UPnP or Jini protocols to the OSGi standard, or how to convert the OSGi standard to the UPnP and Jini protocols. However, there is no mention of how to integrate or control the devices and the device services connected to the control gateway.
The aforementioned many architectures for devices connected to the control gateway can only treat the control gateway and the connected devices as a virtual device bundle if using OSGi defined Device Access standard, and then download the driver based on the virtual device bundle. The driver for the virtual device bundle is the collection of all the individual drivers for the control gateway and the connected devices. With this type of implementation, once a device is removed from the control gateway or a new device is added to the control gateway, the bundle driver is no longer applicable, and the new bundle driver needs to be downloaded.
This type of implementation is neither practical nor effectively since an entire bundle driver needs to be downloaded with only one device removed or added. The process is tedious, time-consuming and ineffective.
The UPnP Device Service defined in the present OSGi standard only provides an interface for converting the non-UPnP devices to UPnP device services so that internal bundles or external UPnP control points can use or control the devices. In addition, the OSGi also provides an UPnP base driver mechanism to the UPnP devices to automatically register the UPnP device services to the service registry of the open service gateway.
Because the open service platform cannot communicate directly with the devices connected to the control gateway, the above connection architecture cannot provide the devices connected to the gateway with the function of conversion to different device service and corresponding device service downloading.
Many current research papers focus on how to integrate non-OSGi network communication protocols or middlewares to the open service platform. For example, Ditze, M. et. al, presented a paper “Service-Based Access to Distributed Embedded device through the Open Service Gateway,”, IEEE Industrial Informatics, pp. 493-498, June 2004. The prior art disclosed how to package the home audio-video interoperability (HAVi) and the devices on the control area network (CAN) as a control service through OSGi Device Access standard and JAVA native interface (JNI), and register to the service registry of the open service home gateway to achieve the goals of integration and control.
Another paper, presented by Dobrev, P., et. al., “Device and Service Discovery in Home Network with OSGi,”, IEEE Communication Magazine, pp. 86-92, August 2002, disclosed the conversion standards between Jini and OSGi, and between UPnP and OSGi. This technique can only convert the Jini and UPnP device services, and the devices must have the capability of device discovery and the capability to be controlled.
The above two papers does not propose a solution for integrating the devices connected to the control gateway into the open service platform. Other patent documents mostly use the generation of a corresponding control mechanism on the open service platform to achieve the control of the devices being controlled by the standard middlewares or network protocols.
U.S. Patent Publication No. 2004/0267950 disclosed a method and an apparatus for using a device control module to control HAVi standard devices. This technique generates the device control module on the open service platform to match the device control module in the HAVi standard structure so as to control the HAVi standard devices.
U.S. Patent Publication 2001/034,754 disclosed a markup-language-type syntax to control the different network communication protocols used in home. Similarly, this document does not propose a solution to integrate the devices connected to the control gateway into the open service platform.
Taiwan Patent Application No. 94145773 disclosed a method for processing the conversion of the devices connected to the control gateway, and how to integrate into the open service platform to achieve the goals of integration and control. This system architecture must place the control gateway base driver on the open platform during the construction phase.
However, in actual applications, there may be many types of control gateways; therefore, it is impossible to build all the control gateway base drivers in the system when the open service gateways are manufactured. Furthermore, the control gateways must obtain their device service from the remote server or component download center through the network. The process is time-consuming and prone to connection interruption.